Users of physical or virtual machines commonly install software packages, including package updates, to physical or virtual machines. The software packages can contain a set of related files chosen to perform a given application or task, such as, for example, a group of software applications, drivers, and/or other resources used to install and use messaging applications. In instances, a software package can contain application software, operating system software, drivers, patches, and/or other software components grouped as a logical set.
Software package update managers exist to help a user initiate and perform software package updates, such as, for example, the “yum” (Yellowdog update manager) package update manager available from Red Hat Inc., and others. In general, available software package managers are configured to interact with the set of installed packages on a client and with one or more software package repositories, to directly connect to those databases and download available package updates. In cases, the package update can be formatted as a single combined file containing the various component files, and can be compressed for easier transmission.
The task of managing a network of physical and possibly virtual machines can be complicated by the need to identify and track the population of the machines under management, and the various software package complements and/or entire software distributions, such as operating system distributions, installed on those machines. The machines under management and their package complements may need to be identified and tracked for a variety of purposes, including, for instance, to identify and schedule package updates, activate and deactivate machines assigned to networks including on-premise and cloud networks, to perform maintenance, or other package or network management tasks.
In various networks, it may be periodically desired by users and/or administrators to perform a distribution upgrade, for instance to update one or more client machines from an installed distribution version of Linux™ and/or other software to a target, presumably upgraded, version of the same distribution. In general regards, if all software packages contained in the installed distribution were present in the target distribution in their most-current or up-to-date form, performing such a distribution upgrade would be a straightforward task.
However, in actuality, the packages contained in the target distribution may not always represent the most-current versions of the same packages already installed (in earlier versions) on the existing distribution hosted by the client. This can occur for a variety of reasons or due to a variety of factors. For one, a software distribution can contain a relatively large number of packages and constituent files of those packages, for instance on the order of hundreds or thousands of packages and/or files. Frequently, the packages (and/or files) contained in a distribution can be contributed by a diverse set of software vendors or other suppliers. For distributions of various types, there may be insufficient coordination between the different vendors to result in the absolutely most-recent version of all (potentially thousands or more) packages being inserted into the overall software distribution. For instance, vendors or other software suppliers frequently patch or update their packages or other files. In many cases, these updates can be labeled or named with a relatively minor or incremental version number update, e.g. from version 3.2 to version 3.3 of the package or software of the same name.
However, incremental or ongoing package updates can take place at any time, including after an overall distribution is finalized and potentially encoded and stored in a software repository or other data store. Package update logic used to retrieve and install updates may not be configured to locate all incremental or other updates for packages in the target distribution. In cases, the most-recent version of a package may be re-named or re-identified by a different package or file name, after the software distribution is finalized.
Further, different software vendors or other contributors may adopt inconsistent naming or versioning schemes for their package updates, depending on time of release and other factors. For instance, one vendor may contribute Package X, Version 2.0 for Distribution A, and within a month of the version being embedded into Distribution A, develop or release version 2.1 of Package X. In an effort to discriminate that version from others, the contributing vendor may label or name that package “Package_X_Distro_A—2.1,” or other complex identifier intended to indicate the distribution with which a package version is correlated.
However, complex identifiers may lead to inconsistencies or confusion in terms of downstream updates and associated distributions. If the same exemplary vendor released a further update to the same package after a further distribution B, they might label that package “Package_X_Distro_B—1.0” or similar. However, if a subsequent package update is made, the vendor may unable to attach a label to that further update that will intelligibly indicate whether that package represents an update to Package_X_Distro_A—2.1, Package_X_Distro13 B—1.0, or both, or neither.
In further regards, the naming conventions and update position of package versions can become yet further complicated if a vendor produces multiple updates for different step versions (e.g., versions 2.2, 2.3, etc. as well as 3.1, 3.2, 3.3, etc.), in which case there may be multiple series of versions, some of which are more recent than others but not all of which may represent an upgrade to each other. Similarly, consistency may become problematic between package versions when a vendor or does not produce an update, or any package at all, for inclusion in additional downstream distribution versions. In those cases and others, the installation logic may wish to revert to a prior version of a software package which still represents the most-recent version, even if a nominally higher-labeled version is incorporated in a distribution or otherwise. In existing installation platforms, the ability to automatically seek, detect, and install the most-recent version of a software package contained in a distribution is not provided. Users are instead relegated to manually searching or confirming that all packages are compatible and up-to-date after performing an update to a distribution.
It may be desirable to provide systems and methods for automatic upgrade and downgrade in package update operations, in which an administrator or other user can initiate a distribution upgrade in which the installation logic can automatically detect and install the most-recent version of constituent packages, regardless of package name or version compatibilities across different package versions and between distribution version upgrades.